System and method for integrating software schedulers and hardware interupts for a deterministic system

ABSTRACT

The problem which is being addressed by this invention is the lack of determinism in mass market operating systems. This invention provides a mechanism for mass market operating systems running on mass market hardware to be extended to create a true deterministic responsive environment. 
     This is accomplished through programming hardware elements of the scheduler to behave deterministically with respect to the software scheduler.

CROSS-REFERENCE TO THE RELATED APPLICATION

This is a utility application which claims the priority benefit of the U.S. provisional application No. 61,336,967 filed on Jan. 28, 2010.

BACKGROUND OF THE INVENTION

The problem which is being addressed by this invention is the lack of determinism in mass market operating systems. This invention provides a mechanism for mass market operating systems running on mass market hardware to be extended to create a true deterministic responsive environment.

SPECIFICATION

Processing power of commodity hardware (PCs) running general purpose operating systems (Windows, Linux) is vastly underutilized with respect to real-time applications. Some embedded hardware running off-the-shelf “real-time” operating systems are underutilized. Average PC has power to simultaneously run 10 real-time apps, but generally can't run more than 2 because of poor real-time environment.

Ubiquitous Problem: Problem is as widespread as PCs running general purpose operating systems are widespread Business workstation user, Home user, Factory automation, Medical industry, Portable devices.

Existing Solutions are incomplete. RTI creates another programming environment hence require a new set of skills for programming. Don't fully leverage the computational power of the hardware in that they are more real-time on-the-side solutions. One example of this is when not all interrupts are incorporated in the stable task set. Consequences of on-the-side solutions is that not all computational power can be leveraged for real-time applications. Most detrimental is that computational requirements (wattage) for the entire system cannot be calculated so that CPU cycles cannot be throttled back to minimize power consumption

Unique RTI Approach includes all computations in the stable task set, interrupt service routines are periods in the stable task set, deferred processing routines are periods in the stable task set, standard tasks are periods in the stable task set and periodic tasks from different schedulers are aggregated into a single stable task set. Additional new programming is limited to a registration procedure for submitting and withdrawing a task from the stable task set. All latencies including interrupts off times and task periods and higher priority entities are accounted for to quantify and harden response times to the point of true determinism. In sections below we give the details on the engineering behind the RTI Libraries

Advantages of RTI approach is that it is legacy compatible, small amount of programming needed to be added to a stable task set, it utilizes all CPU cycles and it allows for absolute minimal use of power by always knowing how far back the CPU frequency can be throttled. Also deterministic back-up times with real-time file systems, bounded search times with real-time data bases, and more secure time based authentication and authorization tokens.

Factory Automation. Single PC based node can run a full real-time network stack while performing real-time data acquisition and performing real-time process control, implement software only real-time publish-subscribe networks, implement software only ATM adaptation layer and above. Tightly coupled networked clusters synchronized on a nanosecond basis.

Tightly coupled process control networks. Involves calibration of NIC and all transmission protocols. Schedule events on different nodes to within a microsecond accuracy both absolutely and relatively. Application in aircraft control, robotics, and factory automation, etc.

Portable devices: A notable advantage is the power savings which can be achieved on portable devices by knowing how far back the CPU frequency can be throttled.

RTI advantage over competitors: The RTI Library is the only solution with the ability to incorporate ALL computation into a stable task set.

Calculation problems which RTI is solving: Period calculations, Latency calculations, Interrupt calculations.

Period calculations can be done by making several assumptions. Consider worst case hardware response and worst case program flow.

Worse case hardware: consider worst case hardware response, worst case program flow.

Worse case flow: Assume worse case program flow, assume any exceptions may be incorporated in the worse case flow, assume any exceptions may be accounted for in another period.

Biased Worse case calculation

${\frac{E_{1}}{P_{1}}\mspace{14mu} \ldots \mspace{14mu} \frac{E_{n}}{P_{n}}} \leq {{n\left( {2^{\frac{1}{n}} - 1} \right)} + C}$

-   -   E:: execution time     -   P:: period of execution     -   C:: constant based on assumptions

Resource registration: Each task must register its time of execution and period (processor percentage) with the OS, OS must keep accounts for all real-time tasks.

Each task must negotiate permission for its computational requirements, each task must include resource usage in its period (except for periodic servers), each task must deregister its requirements when they are no longer needed.

Resource time accounting: All resource calls are either synchronous with a time impact or asynchronous with a binding to periodic server. All resource calls, even when synchronous, are associated with a periodic server, all periodic servers are represented in a device node tree. The device node tree serves as the database for the negotiation which takes place at task registration time.

Flow Chart for Standard Task—See FIG. 1.

Latency calculations: Apply worst case for all contributing factors. One factor is the full period for the event processing task, other factors are the full periods for all indication reporting tasks. Another factor is the worst case CLI—STI duration for the system.

Latency Graph is on FIG. 2.

Interrupt Calculation: Register worst case requirements for device interrupts. Keep interrupts unmasked in anticipation of initial interrupt to start full processing. Full processing involves throttling the interrupt with masks to achieve the designated period.

Full. Interrupt processing: Create a stable task set using the cascaded 8259 scheduling system. Period will be the predetermined ISR frequency which fully satisfies the device. Execution time is the 8259 administrative work and the interrupt processing. The period processing requirements can be registered and deregistered in the stable task set.

Interrupt period: Must control CPU response to the interrupt request signal. Requires signal in Interrupt Request Register (IRR) be masked. Unmasking from high frequency 8254 device. Optimization to 8259 to establish period by deterministic unmasking would be very helpful.

Interrupt Period Flow Chart—FIG. 3.

Deferred processing periods: Period can be same as interrupt, can be an aggregation of interrupts. Assume arbitrary thread context, it can be analyzed as a stable task set.

Summation of Stable Task sets: Stable task sets of different schedulers can be summed. All stable task sets must be on some processor. Stable task sets must account for all tasks on the system of equal or greater priority, stable task sets must account for all other stable task sets on the processor and stable task set summation is used in the negotiations during task registration.

Stable Task Set Summation Formula—Interrupt Periods

${\frac{E_{1}}{P_{1}}\mspace{14mu} \ldots \mspace{14mu} \frac{E_{n}}{P_{n}}} \leq {{n\left( {2^{\frac{1}{n}} - 1} \right)} + C_{8259\; {Scheduler}}} \leq {S_{8259\; {Scheduler}}.}$

-   -   C_(8259 Scheduler):: constant to account for scheduler specifics     -   S_(8259 Scheduler):: summarized stable task set for 8259         scheduler

Stable task set summation formula—interrupt periods and deferred processing periods:

${\frac{E_{1}}{P_{1}}\mspace{14mu} \ldots \mspace{14mu} \frac{E_{n}}{P_{n}}} \leq {{n\left( {2^{\frac{1}{n}} - 1} \right)} + C_{deferred}} \leq {S_{8259\; {Scheduler}} + S_{deferred}}$

-   -   C_(deferred):: constant to account for scheduler specifics     -   S_(deferred):: summarized stable task set for deferred scheduler

Stable task set summation formula—interrupt periods and deferred processing periods and standard task periods:

${\frac{E_{1}}{P_{1}}\mspace{14mu} \ldots \mspace{14mu} \frac{E_{n}}{P_{n}}} \leq {{n\left( {2^{\frac{1}{n}} - 1} \right)} + C_{std}} \leq {S_{8259\; {Scheduler}} + S_{deferred} + S_{std}}$

-   -   C_(std):: constant to account for scheduler specifics     -   S_(std):: summarized stable task set for deferred scheduler

Tools needs: must have all OS resources calibrated for inclusion in the task registration process, compiler must have set of MACROs and PRAGMAs which provide worse case execution times for the task registration process.

Ancillary benefits: task-queue technique generates minimal use of memory, long duration queues create optimized processing through cache coherency. 

1. A method and apparatus to seamlessly integrate hardware event processing with arbitrary thread context derived ISR calls into a scheduling system with continuous priorities.
 2. A method and apparatus to maintain metadata on stable task sets for every priority in the scheduling system.
 3. A method and apparatus to maintain the bounded periodic execution requirements for stable task sets at every priority level.
 4. A method and apparatus to maintain all processing requirements of higher priority (n+X) task sets in the stable task set at priority n. 